Conventionally, game systems attribute user actions based on a one-to-one mapping between a signed-in user and a controller. This may limit the ability of a gamer to interact with a game console simultaneously in a variety of ways, to switch controllers, to move about in a game space, and in other ways. This conventional attribution approach arose because game consoles typically had a concept of a controller and a concept of a user and the only way to connect the user to the controller was through a sign-in procedure. The console may have established and maintained a fixed, one-to-one relationship between a controller and a player. All actions performed from a controller were associated with the user who entered their information from that controller and the only actions the user could perform were those associated with the controller on which the user signed in. In this one-to-one user-to-controller configuration, one user was identified as controlling the console. This control was manifested at the system level by having system level actions (e.g., application launches) associated with the user who controlled the console.
Computer systems, including game systems, may allow multiple users to access, sign in, or otherwise interact with the system at the same time. For example, a single game console may have dedicated controllers and may have the ability to allow additional transient controllers to interact with the game. Thus, multiple players may simultaneously be able to sign into and interact with a multi-user game. Additionally, the game console may allow different players to have different games active at different times and even to come and go from a game. The traditional, fixed, one-to-one relationship between a user and a controller may limit the game experience. This limiting experience may extend to other non-gaming systems.
Different users may have different contexts. A user context may describe, for example, user attributes and user state. User attributes may include, for example, name, language preferences, login credentials for applications, login credentials for websites, saved content including documents or game saves, or other data. User state may include, for example, location, or other data. When there are multiple users signed into a system, there are multiple contexts available to the system. Conventionally, when a user launched an application, the context associated with the application may have controlled, at least in part, the operation of the application. For example, a first user context may have caused an application to produce an English language presentation for a male who is an intermediate level swordsman while a second user context may have caused an application to produce a French language presentation for a female who is an expert archer. The context may have controlled in-game attributes (e.g., point of view, character) but may also have controlled attributes of other applications launched from the launch surface. A launch surface refers to a interface with which a user may interact to launch an application. A launch surface may be, for example, a desktop, a start menu, a dashboard, or other interactive item from which applications or processes can be initiated (e.g., launched). Conventionally, given the one-to-one user-to-controller relationship and the single launch surface owner approach, it may have been difficult, if even possible at all, to change the user context associated with an action.